chore(deps): regenerate requirements-build.lock for hatchling 1.31.0 - #228

Fixes uv.lock rot. Python was the one ecosystem here nothing watched, and it
shows: 19 packages behind (mypy 2.1→2.3, ruff 0.15.18→0.15.21, numpy
2.4.6→2.5.1, …), noticed only because CI went red for an unrelated reason.

This is NOT the fix for #228 and does not stop it recurring. #228 was
`requirements-build.lock`, which is `uv pip compile`d from the *unpinned*
`[build-system].requires` and re-resolved against live PyPI on every CI run —
so the next hatchling release reds every open PR again, exactly as before.
The `uv` ecosystem reads `[project]` deps + uv.lock and never touches
`[build-system].requires`; no ecosystem scans that file at all. Pinning a
floor (`requires = ["hatchling>=1.27,<2"]`) is what retires that, and it is a
separate change. Saying otherwise here would send the next person to hit a
red build-lock check hunting for a new bug instead of a known one.

The omission being reversed was deliberate and correctly reasoned when
written — Dependabot couldn't update uv.lock. That stopped being true when uv
version updates went GA on 2025-03-13. Stale premise, not a judgment call.
Monthly + grouped like the other three: one Python PR a month.

Known rough edge, documented in the file rather than left to be discovered:
Dependabot rewrites uv.lock but not requirements-prod.lock, which CI diffs
against a fresh `uv export`, so a grouped PR bumping any runtime dep lands red
until someone regenerates it on the branch — six of the current nineteen
qualify. The sharper reason not to let that sit is that pip-audit reads
requirements-prod.lock, not uv.lock: until the export is regenerated, a
security bump to a runtime dep isn't actually being audited. Automating it
away is not cheap either — Dependabot-triggered workflows get a read-only
GITHUB_TOKEN, so pushing the export back needs pull_request_target or a PAT.
The manual export is the sane option, not a stopgap.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RR6LwVdry9fmXkEhkC9Cbi

)

This is what actually retires #228. `[build-system].requires` was unbounded,
requirements-build.lock is `uv pip compile`d from it, and CI's drift check
recompiles against live PyPI every run and diffs — so hatchling 1.31.0
shipping reddened every open PR, whatever its diff. #228 regenerated the lock
by hand; that bought time, it didn't fix anything.

A range does not fix it either, which is worth stating because it is the
obvious reach: `uv pip compile` resolves the NEWEST version a specifier
admits, so `>=1.27,<2` re-resolves the day 1.32.0 lands and the lock is stale
again. Measured, not assumed:

    hatchling>=1.27,<2      -> 1.31.0    (newest in range — drifts again)
    hatchling>=1.27,<1.31   -> 1.30.1    (proves it takes the max, not a pin)
    hatchling==1.30.1       -> 1.30.1    (stable)

Only `==` makes compile-then-diff idempotent, which is the property the check
needs. It also fits what this feeds: kayak-deploy builds the wheel with
--no-build-isolation from the hashed lock (#190), so the backend version is
part of the artifact and pinning it is the point, not a wart.

The cost is that nothing watches this line — no Dependabot ecosystem reads
[build-system].requires, so hatchling now goes stale until bumped by hand. A
stale-but-working build backend is a strictly better failure than an
unpredictable red CI, and the comment carries the two-line bump recipe.

Lock unchanged: #228 already put 1.31.0 there, so this only removes the
mechanism that made that a recurring chore. Drift check verified idempotent
across repeated runs; wheel builds clean.


Claude-Session: https://claude.ai/code/session_01RR6LwVdry9fmXkEhkC9Cbi

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Fixes uv.lock rot. Python was the one ecosystem here nothing watched, and it
shows: 19 packages behind (mypy 2.1→2.3, ruff 0.15.18→0.15.21, numpy
2.4.6→2.5.1, …), noticed only because CI went red for an unrelated reason.

This is NOT the fix for #228 and does not stop it recurring. #228 was
`requirements-build.lock`, which is `uv pip compile`d from the *unpinned*
`[build-system].requires` and re-resolved against live PyPI on every CI run —
so the next hatchling release reds every open PR again, exactly as before.
The `uv` ecosystem reads `[project]` deps + uv.lock and never touches
`[build-system].requires`; no ecosystem scans that file at all. Pinning a
floor (`requires = ["hatchling>=1.27,<2"]`) is what retires that, and it is a
separate change. Saying otherwise here would send the next person to hit a
red build-lock check hunting for a new bug instead of a known one.

The omission being reversed was deliberate and correctly reasoned when
written — Dependabot couldn't update uv.lock. That stopped being true when uv
version updates went GA on 2025-03-13. Stale premise, not a judgment call.
Monthly + grouped like the other three: one Python PR a month.

Known rough edge, documented in the file rather than left to be discovered:
Dependabot rewrites uv.lock but not requirements-prod.lock, which CI diffs
against a fresh `uv export`, so a grouped PR bumping any runtime dep lands red
until someone regenerates it on the branch — six of the current nineteen
qualify. The sharper reason not to let that sit is that pip-audit reads
requirements-prod.lock, not uv.lock: until the export is regenerated, a
security bump to a runtime dep isn't actually being audited. Automating it
away is not cheap either — Dependabot-triggered workflows get a read-only
GITHUB_TOKEN, so pushing the export back needs pull_request_target or a PAT.
The manual export is the sane option, not a stopgap.


Claude-Session: https://claude.ai/code/session_01RR6LwVdry9fmXkEhkC9Cbi

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>